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ABSTRACT 

A  diagramming  technique  called  Object-Oriented 
Simulation  Pictures  (OOSPic)  is  presented.  Using 
this  technique,  a  simulation  designer  can  show  the 
relationships  and  interactions  between  object  types. 
OOSPics  also  promote  extensive  bottom-up  object 
testing.  Finally,  if  a  complete  OOSPic  is  constructed 
before  coding  begins,  a  reliable  model  can  be  con¬ 
structed  directly. 

1  INTRODUCTION 

The  pursuit  of  the  perfect  diagramming  technique 
is  a  venerable  occupation  among  computer  scien¬ 
tists.  Among  those  who  specialize  in  computer  sim¬ 
ulations,  works  like  Fishman  (Fishman  1978)  show 
how  flowcharts  can  be  used  to  design  and  commu¬ 
nicate  discrete  event  models.  Languages  like  SLAM 
(Pritsker  et  al  1989)  or  SIGMA  (Schruben  1992)  were 
actually  designed  so  that  the  diagram  drawn  is  the 
computer  simulation.  This  worked  extremely  well  for 
languages  which  concentrated  on  networks  of  queues. 

Recently,  object-oriented  simulation  methods  have 
become  popular,  and  MODSIM  II  (MODSIM  1994) 
has  become  a  tool  used  by  many  simulation  builders. 
The  product  ObjectManager  (Object  Manager  1994) 
facilitates  model  construction  in  MODSIM,  but  does 
not  focus  on  project  design.  What  the  designer  needs 
is  an  easy,  standardized  way  to  show  relationships  be¬ 
tween  objects,  as  well  as  the  impacts  one  object  has 
on  another.  This  work  will  present  a  tool  useful  for 
designing  object-oriented  simulations  in  any  object- 
oriented  simulation  language  which  implements  pro¬ 
cess  interaction  timing.  Simula  (Birtwistle  et  al 
1973),  sim-H-  (Baezner  et  al  1990),  SIMSCRIPT 
(Russell  1983),  and  Maisie  (Bagrodia  1991),  all  fit 
this  paradigm.  We  will  use  MODSIM  structures  and 
terminology  to  facilitate  exposition.  The  reader  need 
not  have  a  background  in  MODSIM,  but  must  un¬ 


derstand  the  basics  of  object-oriented  simulation,  see 
Cox  (Cox  1989),  or  Taylor  (Taylor  1990),  for  an  in¬ 
troduction. 

Object-Oriented  simulation  is  not  new,  and  has  en¬ 
joyed  (endured?)  a  close  relationship  to  other  tech¬ 
nologies  labeled  Artificial  Intelligence.  Systems 
such  as  Zeigler’s  (Zeigler  1990)  are  artifacts  of  this 
relationship,  and  treat  the  object-oriented  simulation 
designer  as  a  well-trained,  state-of-the-art  computer 
scientist.  Most  simulationists  come  from  the  fields 
of  operations  research,  manufacturing,  or  engineer¬ 
ing,  and  could  use  something  simpler  than  Zeigler’s 
DEVS-Scheme. 

In  this  work,  we  present  a  simple  diagramming 
technique  which  Henry  Ford  would  have  been  proud 
of: 

"The  best  ideas  are  simple." 

Henry  Ford 

OOSPics  are  at  home  on  chalkboards,  backs  of  en¬ 
velopes,  or  in  elegant  documentation  of  a  large,  ex¬ 
pensive  simulation.  The  only  tools  required  to  pro¬ 
duce  them  are  pen,  paper,  and  imagination.  While 
we  do  have  aspirations  of  automating  the  OOSPic 
construction  process  and  adding  code  generation  and 
testing,  the  OOSPic  is  a  natural  language  for  simula¬ 
tionists. 

We  have  trained  approximately  two  hundred  (200) 
students  in  object-oriented  design  using  OOSPics, 
and  have  refined  and  simplified  the  technique  with 
their  help.  Diagrams  in  this  article  are  produced  on 
a  computer  for  publication,  but  OOSPics  are  usually 
drawn  by  hand. 

2  WHY  AN  OOSPic 

When  looking  at  object-oriented  model  source 
code,  one  cannot  help  but  feel  as  if  there  are 
lots  of  semi-independent  entities  which  relate  to 
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each  other  in  mysterious  ways.  The  Definition 
Module/Implementation  Module  breakdown  used  in 
MODSIM  is  beautiful  for  exposing  the  workings  of  a 
single  object,  but  there  is  very  little  to  help  expose 
relationships  between  object  types  and  interactions 
between  objects.  Clearly  the  design  process  mostly 
involves  these  relationships,  so  we  need  a  method  for 
describing  them.  We  call  this  method  OOSPic,  short 
for  Object-Oriented  Simulation  Pictures. 

These  diagrams  facilitate 

•  COMMUNICATING  REQUIREMENTS; 

•  DESIGNING  MODELS; 

•  TESTING  MODELS; 

•  DOCUMENTING  MODELS; 

•  LEARNING  ABOUT  OOS. 

One  complete  OOSPic  is  composed  of  three  differ¬ 
ent  kinds  of  diagrams: 

1.  Object  Lay-Out:  shows  the  relationships  be¬ 
tween  object  type  definitions,  as  well  as  relaying 
information  about  how  the  objects  will  act. 

2.  Transition/ Action  Diagram:  shows  the  flow  of  a 
single  method,  and  emphasizes  the  external  ac¬ 
tions  of  the  object. 

3.  System  Drop-Through:  simple  flowchart  show¬ 
ing  how  the  simulation  is  executed. 

The  object  lay-out  shows  which  objects  inherit 
properties  from  other  objects,  set  memberships,  and 
different  types  of  ownership.  Before  we  can  discuss 
these  relationships,  we  need  to  establish  that  a  sin¬ 
gle  object  in  an  OOSPic  is  shown  as  a  tagged,  four¬ 
layered  box,  shown  in  Figure  1. 

1.  The  top  layer  states  the  object's  type  name. 

2.  The  second  layer  lists  all  of  the  fields  of  the  ob¬ 
ject. 

3.  The  third  layer  lists  all  of  the  ASK  (non-time¬ 
consuming)  METHODS  of  the  object. 

4.  The  fourth  layer  lists  all  of  the  TELL  (time- 
consuming)  METHODS  of  the  object. 

The  tag  gives  the  object  another  name,  called  its 
local  name.  We’U  see  the  importance  of  tagging  when 
we  discuss  object  ownership. 

It’s  important  to  state  that  we  are  not  suggesting 
that  all  of  this  information  be  listed  every  time  the 
object  box  is  used  in  the  OCSPic.  For  example,  there 


Figure  1:  An  Object  Box 


may  be  times  when  an  object  box  is  used  to  identify 
a  single  ASK  METHOD  of  the  object.  In  this  case, 
we  simply  omit  the  other  lists.  However,  we  should 
keep  the  separating  bars  in  the  box  so  that  positional 
relationships  are  maintained. 

2.1  Motivating  Example  -  Project  1  of  Intro¬ 
duction  to  System  Simulation:  Remotely 
Controlled  Vehicle 

The  following  is  a  description  of  a  project  undertaken 
in  an  introductory  system  simulation  course  which 
uses  MODSIM.  We  will  use  this  project  to  motivate 
our  discussion  of  the  OOSPic.  The  project  assign¬ 
ment  is  stated  as  follows: 

Design  an  object  which  represents  a  vehicle,  per¬ 
son,  animal,  storm  system,  etc.,  which  is  called  Di- 
rectedMovingObj.  This  object  must  be  controlled  by 
inputting  directions  (speed,  waypoints)  from  the  con¬ 
sole.  All  of  the  user  interactions  and  object  actions 
should  be  recorded  in  an  output  file,  along  with  en¬ 
tries  and  exits  from  all  methods  and  procedures.  The 
following  are  the  steps  involved: 

1.  Design  an  object  called  MovingObj  which  main¬ 
tains  its  own  position  and  velocity,  and  which 
takes  directions.  This  object  should  start  at  (0,0) 
and  have  an  initial  velocity  of  0.  The  definition 
module  for  MovingObj  is  shown  in  Figure  2. 

2.  Inherit  the  MovingObj  into  DirectedMovingObj, 
which  is  a  MovingObj  which  gets  directions  from 
the  user  console  by  asking  questions.  The  object 
should  OUTPUT  its  position  and  the  current 
simulation  time  at  the  end  of  each  move.  Hint: 
This  object  should  WAIT  FOR  itself  to  MoveTo 
in  the  TELL  METHOD  DoGuidedTour.  Figure 
3  shows  the  definition  for  DirectedMovingObj. 

3.  In  a  PROCEDURE  create  a  variable  number 
of  objects  of  type  DirectedMovingObj  and  place 
them  in  an  object  of  type  QueueObj.  TELL  each 
to  DoGuidedTour. 
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DEFINITION  MODULE  Moving; 

{ 

Mika  Bailey 

} 

TYPE 

XYRacTypa  -  RECORD 
X  :  REAL; 

Y  :  REAL; 

END  RECORD; 


Figure  4:  Object  Boxes  for  the  MovingObj,  Full  end 
Abbreviated. 


Mo v ingOb J  -  OBJECT 

Position  :  XYRacTypa; 

Valocity  ;  REAL; 

ASX  METHOD  Objlnit; 

TELL  METHOD  MoveTo(IN  XY  :  XYRacTypa); 

ASK  METHOD  ChangeValocity(IN  Val  :  REAL); 
END  OBJECT; 

END  MODULE. 
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Figure  2:  Definition  module  for  the  MovingObj, 
found  in  file  DNloving.inod 


Figure  5:  Arrow  Symbols  used  in  an  Object  Lay-Out. 
FYom  left  to  right,  they  are  inheritance,  permanent 
ownership,  temporary  ownership,  and  membership. 


Thus,  suppose  that  we  had  an  object  MovingObj 
which  had  an  object  box  as  shown  in  Figure  4.  If  we 
wanted  to  use  an  object  box  which  just  highlighted 
the  ASK  METHOD  Change  Velocity,  we  could  use 
the  abbreviated  box  shown. 


DEFINITION  MODULE  Direct; 

{ 

Mika  Bailey 

} 

FROM  Moving  IMPORT  MovingObj ; 

TYPE 

DiractadMovlngQbj  -  OBJECT (MovingObj) 

TELL  METHOD  DoCuidedTour ; 

{DoCuidedTour  nanages  the  aoveaent  of 
the  object  by  interacting  with  the 
user  to  gat  directions.) 

END  OBJECT; 

Figure  3:  Definition  module  for  DirectcdMovingObj, 
found  in  file  DDircct.mod 


3  OBJECT  LAY-OUT 

An  object  lay-out  should  tell  us  everything  required 
to  define  an  object.  It  also  includes  several  aspects 
which  will  help  the  designer  relay  his  intentions  about 
how  an  object  may  be  used. 

An  object  lay-out  contains  an  object  box  for  every 
object  in  the  model.  Special  arrows  connect  the  boxes 
to  show 

a  inheritance; 

a  permanent  ownership. 

a  temporary  ownership; 

a  membership; 

Our  DirectedMovingObj  shows  its  inheritance  re¬ 
lationship  to  MovingObj  in  Figure  6.  In  addition,  it 
shows  the  membership  relationship  as  each  Directed-  3 
MovingObj  is  a  member  of  the  QueueOfMovers. 


nn 


DtracUdMorlngOt* 

QueueObj 

DoQukterfTeur 
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MeetnfObj 
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hkmfTo 

Figure  6:  Object  Lay-Out  for  the  MovingObj  Project. 

Some  interesting  notes  about  the  object  lay-out  of 
DirectedMovingObj; 

1.  This  is  the  lay-out  of  a  subset  of  the  key  com¬ 
ponents  in  the  simulation  model  -  all  of  these 
diagrams  are  useful  in  building  and  document¬ 
ing  pieces  of  models. 

2.  If  DirectedMovingObj  included  an  OVERRIDE 
of  a  METHOD  of  MovingObj,  we  would  see  this 
by  observing  the  same  METHOD  name  in  both 
MovingObj  and  DirectedMovingObj. 

3.  QueueOfMovers  is  the  local  name  of  the 
QueueObj  object  which  contains  DirectedMovin¬ 
gObj  instances.  The  object  box  tag  tells  us  this. 

4.  The  QueueObj  object  box  is  empty,  no  details 
are  required.  QueueObj  is  a  standard  MODS1M 
object  type  and  is  well  documented  in  (MODSIM 
1994). 

To  see  the  ownership  features  of  an  object  lay-out, 
let’s  suppose  that  we  have  an  object  called  a  Ve- 
hicleObj,  which  inherits  all  of  the  properties  of  the 
MovingObj,  and  which  has  a  permanent  Engine  and 
which  may  carry  Cargo.  The  object  lay-out  for  the 
engine  is  shown  in  Figure  7. 

Note  the  two  different  kinds  of  arrow  relating  the 
Engine  to  the  VehideObj  and  the  Cargo  to  the  Ve- 
hicleObj.  FYom  this  diagram  we  can  expect  many 
different  LoadObj’s  to  be  attached  to  a  VehicleObj, 
however  the  VehicleObj  has  a  single  permanent  En¬ 
gine  during  the  simulation.  Also  notice  the  use  of 
the  tags.  This  identifies  the  PowerPlautObj  with  the 
Engine  field  of  the  VehicleObj.  The  VehicleObj  de¬ 
signer  may  even  decline  to  list  Engine  as  a  field  of 
VehicleObj  because  of  the  tag  on  the  PowerPlautObj. 

4  TRANSITION/ACTION  DIAGRAMS 

Each  important  METHOD  of  each  object  should  have 
its  own  transition/action  diagram.  This  diagram  is 


Figure  7:  Object  Lay-Out  Showing  Permanent  and 
Temporary  Ownership.  The  Engine  is  a  permanent 
component  of  the  VehicleObj,  but  the  Cargo  may  be 
swapped  in  and  out  several  times  during  the  simula¬ 
tion. 

closely  related  to  the  well-known  flowcharts  first  used 
in  the  1950’s,  but  has  been  tailored  to  object-oriented 
simulation  use. 

4.1  lYansitions 

In  each  METHOD  of  an  object,  the  object  may  be 
thought  of  as  rolling  through  a  set  of  states.  These 
slates  are  of  two  distinct  types: 

1.  PERSISTENT  STATES:  The  object  is  sus¬ 
pended  and  simulation  time  is  elapsing. 

2.  TRANSIENT  STATES:  The  object  is  doing  one 
or  both  of  the  following: 

(a)  developing  some  important  data  product; 

(b)  interacting  with  other  objects. 

In  these  cases,  the  simulation  clock  is  frozen  while 
the  object  is  in  the  transient  state.  See  Figure  8.  We 
use  boxes  to  indicate  states,  thick  walls  for  persistent 
states  and  thin  walls  for  transient  states. 

The  METHOD  flows  from  one  state  to  another  ac¬ 
cording  to  simple  arrows.  In  order  to  show  logical 
flow,  we  need  two  relics  of  the  traditional  flow  chart, 
the  decision  and  the  loop.  Decisions  are  indicated 
by  diamonds,  while  loops  flow  with  the  arrows.  See 
Figure  9. 
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Figure  8:  State  Boxes  for  Transient  (thin  walls)  and 
Persistent  (thick  walls)  States. 


Figure  9:  Decisions  and  Loops. 


Figure  10:  lYansition/Aclion  Diagram  for  DoGuid- 
edTour.  Only  the  transitions  are  shown. 


These  symbols  are  all  that  we  need  to  describe 
the  transitions  that  the  object  takes  on.  The  TELL 
METHOD  DoGuidedTour  of  the  DirectedMovingObj 
has  the  transitions  as  shown  in  Figure  10.  Note  the 
use  of  the  -ing  suffix  in  all  of  the  state  descriptions. 
This  encourages  us  to  anthropomorphize  the  object, 
and  to  account  for  all  of  its  actious. 

When  designing  an  object  METHOD,  the  designer 
can  simply  scribble  out  the  states  as  they  come  to  his 
mind.  However,  when  preparing  more  formal  tran¬ 
sition/action  diagrams,  the  separation  of  states  can 
be  important.  We  suggest  that  the  separation  be  as 
follows: 

1.  PERSISTENT  STATES:  one  state  identified  per 
WAIT  in  the  implementation  code. 

2.  TRANSIENT  STATES:  one  state  identified  per 
important  data  product,  and  one  state  per  im¬ 
portant  action. 

4.2  Actions 

Actions  are  all  those  things  which  an  object  does  that 
involve  other  METHODS  or  other  objects.  These  ac¬ 
tions  include: 

1.  starting  other  METHODS; 

2.  querying  other  object's  fields  or  invoking  ASK 
METHODS  which  return  values; 

3.  starting  an  INHERITED  method; 

4.  delivering  data  to  another  object; 

5.  WAITing  for  another  object  to  finish  a  TELL 
METHOD. 

The  sequence  in  Figure  11  shows  the  symbols  for 
each  of  these  actions. 

1 .  Starting  a  TELL  METHOD:  a  simple  arrow  from 
a  transient  state  box  to  an  object  box  with  its 
TELL  METHOD  listed. 

2.  Getting  data:  looping  arrow  Rom  a  transient 
state  box  to  an  object  box,  the  information  pro¬ 
vided  is  shown  in  the  object  box  by  listing  fields 
or  ASK  METHODS  which  return  values. 

3.  Delivering  data:  straight  arrow  from  transient 
state  box  to  an  object  box.  The  object  box  shows 
the  ASK  METHOD  which  receives  the  data. 

4.  Inherited  METHOD:  thick  arrow  pointing  into 
a  persistent  or  transient  state  box  from  an  ob¬ 
ject  box.  The  object  box  shows  the  METHOD 
inherited,  the  type  of  the  state  box  depends  on 
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Figure  11:  Actions.  From  top  to  bottom,  they  are 
start  a  TELL  METHOD;  Get  data  from  a  field  or  by 
invoking  an  ASK  METHOD;  Deliver  data  to  another 
object;  Start  an  inherited  METHOD;  WAIT  FOR  a 
TELL  METHOD 


Figure  12:  Full  lYansition/Aclion  Diagram  for 
DoGuidedTour. 


whether  the  inherited  METHOD  is  an  ASK  or 
TELL. 


5.  WAIT  FOR:  looping  arrow  from  persistent  state 
box  to  an  object  box.  The  object  box  lists  the 
TELL  METHOD  which  is  WAITed  FOR. 


The  full  transition/action  diagram  for  DoGuided¬ 
Tour  is  shown  in  Figure  12.  Note  that  the  inherited 
METHODS  involved  are  labeled  as  actions  taken  with 
SELF  as  a  MovingObj.  The  SELF  label  always  tips 
off  the  use  of  an  inherited  METHOD.  Hence,  the  Di- 
rectedMovingObj  will  deliver  data  to  its  own  ASK 
METHOD  ChangeVelodty,  it  wiU  WAIT  FOR  itself 
to  execute  the  TELL  METHOD  MoveTo,  and  it  will 
change  its  own  Position  field. 
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Figure  13:  System  Drop-Through. 

5  SYSTEM  DROP-THROUGH 

Simulation  models  run  inside  simulation  executives. 
This  executive  subprogram  is  not  a  METHOD  of  an 
object,  it’s  simply  a  PROCEDURE  which  initializes 
the  system,  does  replications,  collects  data,  and  per¬ 
forms  output  analysis  procedures.  Often  a  simulation 
is  reused  to  do  several  different  analyses  by  changing 
only  this  process. 

The  diagram  we  use  to  design  and  communicate 
the  simulation  executive  is  called  the  system  drop- 
through.  It  consists  of  a  single  transition/action  di¬ 
agram  with  no  persistent  states.  It  may  be  decom¬ 
posed  into  modular  procedures,  but  it  always  has  a 
linear  flow.  Below  we  see  the  simple  system  drop- 
through  for  the  project. 

6  TESTING 

Testing  any  computer  program  relies  mostly  on  com¬ 
mon  sense  and  careful  work.  Testing  an  object- 
oriented  simulation  is  often  a  difficult  concept  be¬ 
cause  of  the  object's  autonomy  and  flexibility.  How¬ 
ever,  these  were  the  same  reasons  we  used  to  justify 
constructing  the  OOSPic.  As  it  turns  out,  our  pic¬ 
tures  facilitate  testing  our  objects  and  our  system. 
We  should  pursue  testing  in  the  nested  frameworks 
shown  in  Figure  14. 

Manufacturing  technology  of  durable  goods  like  au¬ 
tomobiles  was  revolutionized  by  emphasizing  testa¬ 
bility  in  the  design  of  the  product.  A  modern  car 
designer  includes  test  equipment  iu  the  car’s  design, 
and  specifies  the  testing  the  cur  will  uudergo  during 
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Figure  14:  Nested  Testing. 

manufacture.  We  should  do  the  same  in  our  software 
design.  Planning  tests  must  be  done  during  the  de¬ 
sign  phase  of  the  project.  We  start  from  the  inside 
and  work  our  way  out. 

6.1  METHOD  Tests 

Action/transition  diagrams  show  the  decomposition 
of  METHODS  into  states  where  important  data  prod¬ 
ucts  are  developed,  decisions  are  made,  and  simu¬ 
lation  time  elapses.  To  test  the  performance  of  a 
METHOD,  we  simply  need  to  verify  that  the  devel¬ 
oped  data  products  are  correct,  the  decisions  made 
are  the  right  ones,  and  that  the  timing  of  the  WAITs 
is  correct. 

Hence,  transition  out  of  a  state  is  an  obvious  point 
for  checking  the  state’s  results.  These  results  are: 

•  values  of  data  developed  or  attained; 

•  results  of  decisions; 

•  the  simulation  clock  time  after  a  persistent  state. 

Each  METHOD  should  be  exercised  in  every 
branch  and  for  every  important,  foreseeable  situation. 

6.2  Object  Tests 

Looking  at  an  object  lay-out,  we  find  everything  in  an 
object  that  should  be  tested  -  these  are  the  METH¬ 
ODS  of  the  object.  The  suggested  methodology  is 
to  construct  a  testing  MAIN  MODULE  for  each  ob¬ 
ject  type.  This  process  should  start  with  the  objects 
which  are  base  types,  those  that  do  not  inherit  any 
other  object’s  properties,  and  which  are  not  owned 
by  another  object.  One  instance  of  the  object  should 
be  created.  The  object’s  METHODS  should  all  be  ex¬ 
ercised  and  all  of  the  output  should  be  collected  in  a 
file.  This  file’s  contents  should  be  checked  for  correct 
responses  from  the  object,  then  should  be  renamed 
and  kept. 

Hence,  at  the  end  of  this  process,  we  have  files: 

1.  "M"  +  object  name  -1-  ".mod"  -  the  MAIN  used 
to  test  the  object. 
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2.  object  name  +  ".teat*  (or  a.tst*)  -  output  from 
execution  of  the  test  program. 

These  test  programs  and  their  results  should  be 
archived  by  the  developer.  When  the  object  is 
changed  or  inherited,  the  test  program  can  be  recoin* 
piled  and  rerun  to  check  for  consistency  with  older 
versions. 

6.S  System  Tests 

Finally,  the  system  drop>through  diagram  can  be  used 
to  generate  tests  of  the  entire  model.  Every  state  in 
the  system  drop-through  is  a  breakpoint  where  cor* 
rect  performance  can  be  tested.  Let's  look  at  the 
OOSPic  for  the  Mover  project.  We  wish  to  test 
the  METHOD,  OBJECTS,  and  SYSTEM  for  this 
project. 

Testing  the  system  with  the  DirectedMovingObj 
objects  can  be  partially  done  as  follows.  Inside  the 
TELL  METHOD  DoOuidedTour,  the  following  infor¬ 
mation  should  be  collected  as  indical<  J  in  the  tran¬ 
sition/action  diagram: 

1.  the  Name  assigned  to  the  object; 

2.  the  destination  and  velocity  the  user  requests; 

3.  the  simulation  clock  time  at  the  end  of  the 
WAIT; 

4.  the  object’s  new  position. 

Figure  15  shows  the  transition/action  diagram  for 
DoCuidedTour  annotated  for  testing.  When  planning 
testing  using  a  hand-drawn  OOSPic,  we  suggest  that 
the  designer  photocopy  the  transition/action  diagram 
and  use  colored  pens  to  make  the  testing  annotations. 

Testing  the  DirectedMovingObj  should  not  be  un¬ 
dertaken  until  the  MovingObj  is  tested.  Once  that 
is  accomplished  and  the  files  MMovingObj.mod  and 
MovingObj.tst  are  safely  tucked  away,  we  can  cre¬ 
ate  MDirectedMovingObj.mod.  The  contents  of  this 
module  can  be  seen  in  Figure  16. 

T  OOSPic s  for  ADVANCED  MODSIM 

In  this  final  section,  we  address  some  more  advanced 
MODSIM  capabilities  which  can  also  be  diagrammed 
using  OOSPics.  These  are: 

1.  Interrupts  of  TELL  METHODS; 

2.  TiggerObjs:  used  to  synchronize  object  activi¬ 
ties  by  using  an  ASK  METHOD  Fire; 


Figure  15:  Testing-Annotated  Transition/ Action  Di¬ 
agram. 


Ml IB  NODULE  DirectedMovingObj; 

FROM  Direct  IMPORT  DiractMovingObj ; 

VAR 

Mover:  DirectedMovingObj; 

BEG  Ik 

NEV (Mover) ; 

TELL  Mover  TO  DoCuidedTour; 

END  MODULE. 

Figure  16:  Definition  module  for  the  MovingObj, 
found  in  file  DMovingmod 


3.  ResourceObjs:  manage  a  pool  of  resources. 
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Figure  18:  Action  Diagram  for  using  a  TriggerObj. 
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Figure  19:  Action  Diagram  for  using  a  ResourceObj. 


Figure  17:  Action  Diagram  for  an  Interrupt. 

7.1  Interrupt 

Any  persistent  state  is  associated  with  a  WAIT  in 
the  MODSIM  code,  so  the  exit  from  the  persisteut 
state  can  be  caused  by  the  WAIT  ending  successfully, 
or  by  the  WAIT  being  interrupted.  The  latter  may 
be  handled  in  the  OOSPic  transition/action  diagram 
using  a  simple  decision. 

To  show  a  METHOD  causing  an  interruption  of 
another  object’s  TELL  METHOD,  we  need  a  new 
action  symbol,  seen  in  Figure  17  as  the  arrow  with 
the  "X"  on  it.  The  TELL  METHOD  interrupted  is 
shown  in  the  object  box. 

7.2  TVlggerObj 

A  trigger  object  can  impact  another  object  by  stop¬ 
ping  the  flow  of  a  TELL  METHOD  until  the  trig¬ 
ger  object  executes  its  Fire  Method.  Hence,  the  ap¬ 
propriate  symbol  is  the  WAIT  FOR.  Distinguishing 
the  WAIT  FOR  trigger  from  the  generic  WAIT  FOR 
only  requires  a  look  at  the  object  box,  where  an  ASK 
METHOD  Fire  is  shown. 

7.3  ResourceObj 

WAlTing  for  a  resource  is  like  WAITing  for  a  trig¬ 
ger,  except  that  resource  WAITing  can  be  special¬ 
ized  using  timed  WAIT  FORs,  or  prioritized  WAIT 
FORs.  In  either  case,  simple  annotation  is  all  that  is 
required  to  show  these.  The  object  box  must  show  the 
Give  METHOD  as  the  METHOD  we  WAIT  FOR.  In 
the  case  of  the  TYiggerObj  and  the  ResourceObj,  the 


reader  knows  something  funny  is  going  on  because 
the  diagram  shows  a  persistent  state  WAIT  FORing 
an  ASK  METHOD. 

8  CONCLUSION 

In  this  work,  we  have  presented  a  way  to  design  and 
document  object-oriented  simulation  models  using  di¬ 
agrams.  We  have  focused  on  one  particular  OOS  lan¬ 
guage,  MODSIM,  only  so  much  as  we  have  incorpo¬ 
rated  the  essential  capabilities  and  vernacular  of  this 
language.  The  diagramming  paradigm,  C  DSPic,  al¬ 
lows  us  to  communicate  about  the  structure  of  ob¬ 
jects  and  their  interactions  during  simulation.  It  is 
foreseen  that  some  tool  similar  to  ObjectManager  will 
eventually  incorporate  and  enhance  this  diagramming 
technique. 
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